MySQL INTERVAL(N, n1, n2, ...) comparison function — returns index of last value less than N, or 0 if N < n1, or -1 if N is NULL.

Binder disambiguation (base_binder.go): The old code in BindFuncExprImplByPlanExpr blindly rewrote ALL interval calls to ListExpr. The fix moves the rewrite to bindFuncExprImplByAstExpr where the AST shape is checked: only INTERVAL 5 DAY (2 args with *tree.TimeUnitExpr second arg) becomes ListExpr. INTERVAL(n, n1, n2) passes through to normal function binding.

Implementation (func_builtin.go): intervalParam wraps each arg vector with float/decimal accessors. Binary-search-like linear scan finds the first index where comparator < N. Supports int, uint, float, decimal, and string input types. Decimal comparison path preserves scale. Test matrix covers 20+ cases including the MySQL manual example.

Grammar: INTERVAL '(' bit_expr ',' expression_list ')' in mysql_sql.y — parser now recognizes the function form.

LGTM.

我这轮没有再挖到新的硬 correctness blocker，但按高标准看，当前 coverage 还差一条最关键的 parser/binder 回归用例。

这次 PR 的风险不只是 INTERVAL(...) 这个 builtin 本身能不能算对，更关键的是：加了它以后，现有的 INTERVAL 1 DAY / time-window rewrite 这些老语法有没有被误伤。

现在我看到的是：

• func_interval.sql 把 INTERVAL(...) 本身测得比较全；
• binder/unit 侧也补了 disambiguation test；
• query_builder.go 里把 time-window rewrite 改成了 NewTimeUnitExpr(...)；

但还缺一条真正走到 SQL 执行层的混合回归，比如在同一条查询里同时出现：

• INTERVAL(value, ...)
• ts + INTERVAL 1 DAY 或 time-window 用法

这样才能真正锁住 parse → bind → rewrite → execute 这一整条链路没有被新 builtin 打歪。

所以我这边建议至少补一个很小的 SQL/BVT：把 INTERVAL(...) 和 INTERVAL 1 DAY / time-window 语法放在同一条查询或同一个 case 里，确认两条语义都还对。代码本身这版基本可以，但这个产品级回归点我建议补上再过。